home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 2
/
Aminet AMIGA CDROM (1994)(Walnut Creek)[Feb 1994][W.O. 44790-1].iso
/
Aminet
/
mus
/
play
/
DES_Tracker2_00.lha
/
DTL
/
DTL0-Format.TXT
next >
Wrap
Text File
|
1993-12-17
|
8KB
|
161 lines
Description of the DES-Tracker v1.0 file format ("DTL0")
========================================================
As of Dec 18, 1993
Written by Darren Schebek
Copyright ©1993 by Darren Schebek
All rights reserved
This text file contains a description of the DES-Tracker v1.0 song module
file format, henceforth referred to as the "DTL0" format.
For those familiar with various module file formats, the "DTL0" file
format is most closely related to the Soundtracker v2.6 file format. As such,
this is not an IFF format. Rather, it's just another file format thrown on
the heap. However, it's more efficient and flexible than the Soundtracker
v2.6 format (which is already *way* more efficient than the Noisetracker/
Protracker file format), resulting in smaller module files.
There are a few features worth noting about the "DTL0" file format.
First, like with Soundtracker, patterns are 256 bytes long. A "pattern" in
this context is an array of 64 longword note events to be played by a single
audio channel. The "DTL0" format can handle up to 65,535 patterns in a single
song file. Soundtracker v2.6 can only handle up to 255.
As a result of the above feature, the pattern sequence table requires
4-word elements (instead of 4-byte, like Soundtracker v2.6) in order to
specify pattern numbers greater than 255. The "DTL0" file format is smart, in
that it will store 4-byte elements in the pattern sequence array if the number
of unique patterns is less than or equal to 256. If the number of unique
patterns is greater than 256, then 4-word elements are stored.
Also, the pattern sequence array has only as many elements as there are
positions in the song. If a song has 18 positions, then the array will be 18
elements long in the file. Soundtracker v2.6 always contains an array of 128
4-byte elements regardless of how many elements are actually used.
Lastly, extra fields have been added to indicate intial timing conditions
for the song. One or two of these fields are rather specific to DES-Tracker,
but they may still be of use to others nonetheless.
Here is a byte-by-byte description of the file:
File Field
Offset Size Description
0 4 Four-byte ID code: "DTL0" indicating that this is
a "DTL0" file format.
4 20 The title of the song, padded with NULL's.
24 930 Instrument info blocks. There are 31 of them, and
each one is 30 bytes in length. An instrument info
block looks like this:
22 bytes Instrument's name.
2 bytes Length of instrument sample in words.
1 byte Its fine tune value (-8..+7).
1 byte Its default volume (0..64).
2 bytes Its repeat offset in words.
2 bytes Its repeat loop length in words.
An instrument info block with a length field that
contains 0 is to be considered an "empty slot"
(i.e., No instrument sample is associated with this
instrument info block).
954 1 Playback flags. There are currently two of them:
Bit 0: Timing mode for playback. 0 = 60Hz playback.
1 = 50Hz playback.
Bit 1: Tempo interpretation. If this bit is 0,
then SETTEMPO (command $F) operands are to
be considered as such:
0..31 = Normal tempo operands.
32..255 = BPM tempo operands.
If this bit is set to 1, then the
entire range (1..255) of the SETTEMPO
operand field is to be considered a
normal tempo operand (i.e., No BPM
tempos).
955 1 Default (initial) tempo for playback (0..255).
956 1 Fine tempo for playback. This is a value in the
range -128..127. It represents a fine adjustment
to the overall tempo of the song in units of
0.078125Hz. So, a value of 127 increases the
overall tempo of the song by +10Hz, whereas a value
of -128 decreases the overall tempo by -10Hz.
957 1 Default number of iterations (0..255). A value of
0 here means that the song is meant to loop
forever. 1 means play the song once and then stop,
2 means play it twice, etc.
958 2 The number of positions in the song (referenced in
this document as nPos). This is a value that should
never be higher than 128. It is a word for the sake
of future consideration. If this file format HAS a
future, I should say. :)
960 2 The number of unique patterns in the song
(referenced here with nPatt). Patterns are 256
bytes long, containing 64 longword note events for a
single audio channel.
962 nPos * ( (nPatt > 256) ? 4 : 8)
The pattern sequence array. Each element in the
array contains four pattern numbers - one for each
audio channel that are to be played simultaneously.
If the number of patterns is 256 or less then the
pattern numbers will be byte values (4-byte array
elements). If the number of patterns is greater
than 256 then the pattern numbers will be word values
(4-word array elements).
Varies nPatt * 256 The pattern data. There are nPatt patterns here.
Each one is 256 bytes in length. Protracker
effects and "E" commands are allowed.
Varies Varies The instrument sample data appears here, immediately
after the last pattern. Sample data appears in the
same order as the corresponding instrument info
block (described previously). There is no sample
data for "empty slots" (i.e., instrument info blocks
with a length field containing 0).
EOF
That's about all there is to it. I would probably not have designed the
"DTL0" file format had I not actually come across a song module that had over
256 unique patterns when converted from Protracker to Soundtracker v2.6. This
made me realize that such a thing is possible, and as I detest the
inefficiency of the Noisetracker/Protracker file format, I felt I should come
up with a variation of Soundtracker v2.6 that could handle more unique
patterns. Nobody is obligated to use this format and in all truth, perhaps
nobody really should use it. However, it's perfectly safe to use, as
DES-Tracker can easily convert back and forth between DTL0 and NoiseTracker/
Protracker.
Note that I decided to retain the storage of "empty" instrument info
blocks to preserve instrument names that have been stomped for the sake of
a silly message. This is normally a practice I abhor since it's only going
to cause problems in the long run. Really, SampleTexts are a much, much
better idea and you can say a lot more with them. They're a far better
alternative to stomping instrument names. If you want to stomp instrument
names, give them names like "Inst1", "Inst2", etc, or something. Although
there's absolutely no point in eradicating instrument names in the first
place.
- Darren Schebek
dschebek@outb.wimsey.bc.ca